Your PR requires formatting changes to meet the project's style guidelines.
Please consider running Runic (git runic main) to apply these changes.

diff --git a/lib/mtl/events.jl b/lib/mtl/events.jl
index 374f4285..8d2345ed 100644
--- a/lib/mtl/events.jl
+++ b/lib/mtl/events.jl
@@ -29,9 +29,11 @@ function MTLSharedEvent(dev::MTLDevice)
     return obj
 end
 
-function waitUntilSignaledValue(ev::MTLSharedEvent, value, timeoutMS=typemax(UInt64))
-    @objc [ev::id{MTLSharedEvent} waitUntilSignaledValue:value::UInt64
-                        timeoutMS:timeoutMS::UInt64]::Bool
+function waitUntilSignaledValue(ev::MTLSharedEvent, value, timeoutMS = typemax(UInt64))
+    return @objc [
+        ev::id{MTLSharedEvent} waitUntilSignaledValue:value::UInt64
+        timeoutMS:timeoutMS::UInt64
+    ]::Bool
 end
 
 ## shared event handle
diff --git a/src/state.jl b/src/state.jl
index 0782db68..918731c4 100644
--- a/src/state.jl
+++ b/src/state.jl
@@ -61,7 +61,7 @@ end
 Return the `MTLSharedEvent` used to synchronize a queue
 """
 function queue_event(queue::MTLCommandQueue)
-    get!(task_local_storage(), (:MTLSharedEvent, queue)) do
+    return get!(task_local_storage(), (:MTLSharedEvent, queue)) do
         MTLSharedEvent(queue.device)
     end::MTLSharedEvent
 end
@@ -82,7 +82,7 @@ First-In-First-Out manner, this synchronizes the GPU.
     cmdbuf = MTLCommandBuffer(queue)
     MTL.encode_signal!(cmdbuf, ev, val)
     commit!(cmdbuf)
-    MTL.waitUntilSignaledValue(ev,val)
+    MTL.waitUntilSignaledValue(ev, val)
     return
 end
 

Is there a Metal3->4 migration document anywhere indicating we should switch from MTLCommandBuffer::waitUntilCompleted to a shared event?

Nope. I couldn't find anything from Apple's documentation that mentioned full command queue synchronization. Seems like they're more focused on more granular synchronization with the new API.

The benchmarks seem to indicate that this is slower for Metal 3, so maybe we leave it as-is for metal 3 and only transition to event-based synchronization for Metal 4 command queues. What made me believe that this is how they expect us to do it with Metal 4 is that MTL4CommandQueue has a new signalEvent method which allows to signal without creating a command buffer.

I'm closing this PR to avoid polluting the PR list, and I linked to this PR in #612 for when I (or someone else) get around to finishing metal 4 support.

We can always reopen if someone thinks we should use MTLSharedEvents for Metal 3 synchronization. Locally and using the crude @time Metal.synchronize() in the repl, shared events was giving me similar performance with more consistent timings than with waitForCompleted, but these benchmarks show a regression so I'll trust the benchmarks for now

these benchmarks show a regression so I'll trust the benchmarks for now

Synchronization itself seems slower, but all other operations seem slightly faster. Or is this just the noise of the benchmarks? It's awfully consistent. And I could imagine the microbenchmark being slower while real-use application being beneficial.

all other operations seem slightly faster

Good point. I'll rerun and if results are similar I'll merge

Codecov Report

❌ Patch coverage is 90.00000% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 80.96%. Comparing base (422c43f) to head (4d18869).
⚠️ Report is 1 commits behind head on main.

@@            Coverage Diff             @@
##             main     #633      +/-   ##
==========================================
- Coverage   80.97%   80.96%   -0.01%     
==========================================
  Files          61       61              
  Lines        2712     2722      +10     
==========================================
+ Hits         2196     2204       +8     
- Misses        516      518       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.